File input problem
in [CSS]
|
Prev: Help with a Table Wanted
Next: background shorthand
From: Mark Smith on 15 Dec 2009 12:05 On Dec 15, 4:54 pm, Harlan Messinger <hmessinger.removet...(a)comcast.net> wrote: > Mark Smith wrote: > > On Dec 15, 3:51 pm, Harlan Messinger > > <hmessinger.removet...(a)comcast.net> wrote: > >> Mark Smith wrote: > >>> On Dec 15, 3:15 pm, Harlan Messinger > >>> <hmessinger.removet...(a)comcast.net> wrote: > >>>> Mark Smith wrote: > >>>>> On Dec 15, 2:33 pm, Harlan Messinger > >>>>> <hmessinger.removet...(a)comcast.net> wrote: > >>>>>> Mark Smith wrote: > >>>>>>> On Dec 15, 1:19 pm, Harlan Messinger > >>>>>>> <hmessinger.removet...(a)comcast.net> wrote: > >>>>>>>> Mark Smith wrote: > >>>>>>>>> On Dec 11, 1:06 pm, Harlan Messinger > >>>>>>>>> <hmessinger.removet...(a)comcast.net> wrote: > >>>>>>>>>> David Mark wrote: > >>>>>>>>>>> On Dec 7, 6:54 am, Stefan Weiss <krewech...(a)gmail.com> wrote: > >>>>>>>>>>>> On 07/12/09 11:50, Mark Smith wrote: > >>>>>>>>>>>>> Oh, and for anyone else that is interested, I found an option 5. Ajax > >>>>>>>>>>>>> uploads seem to be triggerable from script: > >>>>>>>>>>>>>http://valums.com/wp-content/uploads/ajax-upload/demo-jquery..htm > >>>>>>>>>>>> Did you look at how this was actually implemented? Apart from requiring > >>>>>>>>>>>> JQuery, that demo page has file upload fields with opacity:0 overlayed > >>>>>>>>>>>> above its buttons and links. I'd say this qualifies as > >>>>>>>>>>>> | #3 Use some hacky CSS and overlays to style the file picker. > >>>>>>>>>>> Yes. Most Web developers (or "designers") want everything to look > >>>>>>>>>>> exactly the way they want it to look and never mind what the user > >>>>>>>>>>> agent thinks. CSS "resets", brittle hacks, anything goes if it makes > >>>>>>>>>>> it look exactly the same in IE, FF and Safari. It's backwards as the > >>>>>>>>>>> developers of the user agents probably had a good idea of what sort of > >>>>>>>>>>> default style would work best for inputs (buttons particularly). > >>>>>>>>>> Imagine if every song you downloaded were to impose its producer's own > >>>>>>>>>> conception of how music player controls should look on your music > >>>>>>>>>> player, or if the display of the volume control bar on your TV screen > >>>>>>>>>> depended on what channel or program you were watching. Perhaps a station > >>>>>>>>>> broadcasting a slasher film would want your volume control display to > >>>>>>>>>> look like it was dripping with blood. Wouldn't that be awesome? (being > >>>>>>>>>> ironic) > >>>>>>>>> I think the anology needs taken one step further to reflect where we > >>>>>>>>> are currently with web standards. > >>>>>>>>> Imagine if every song you downloaded sounded different on every type > >>>>>>>>> of player - not how the musician intended. Wouldn't that be awesome? :) > >>>>>>>> Music does sound different depending on the player and device. The music > >>>>>>>> coming out of my Treo sounds very different from the sound coming out of > >>>>>>>> my Toshiba Satellite's built-in speakers, and different again from the > >>>>>>>> sound that comes out of my Onkyo tuner through my five KLM speakers. In > >>>>>>>> addition, the sound coming out of my Onkyo can sound "multidimensional", > >>>>>>>> and I can apply MY choice of sound distribution, and the musicians can't > >>>>>>>> do a damn thing about it. > >>>>>>> Type of speaker, distribution, sound levels, post processing effects > >>>>>>> etc are analogous to the screen type, browser zoom, window size > >>>>>>> controls etc, i.e. they are under the user control and can override > >>>>>>> the defaults (if they wish). > >>>>>>> Playlist management and navigation controls are analogous to the > >>>>>>> browser address bar, back forward and history, i.e. nothing to do with > >>>>>>> the content provider. > >>>>>>> Elements on a web page however are like the instruments in music. > >>>>>>> Having css styles applied to some elements on some browsers but not > >>>>>>> others is like having a cd player that (without being asked) replaces > >>>>>>> all percussion instruments on a track with a crappy sounding keyboard > >>>>>>> synthesiser! (It's a mess and the standards need fixed). > >>>>>> Your notion that the same considerations apply uniformly to anything > >>>>>> that is part of the web page is flawed. > >>>>> I didn't start the analogy. > >>>>>> Form controls are user interface > >>>>>> devices, regardless of the fact that they are on the page rather than > >>>>>> built into the browser, and therefore there are considerations that > >>>>>> apply to them independently of those that apply to lists and tables. > >>>>> If that's the case, the standards still need fixed to specify that it > >>>>> is up to the agent. > >>>> It can't be fixed to specify that because it already specifies that: > >>>>http://www.w3.org/TR/CSS21/conform.html#conformance > >>>> "CSS 2.1 does not define which properties apply to form controls and > >>>> frames, or how CSS can be used to style them. User agents may apply CSS > >>>> properties to these elements. Authors are recommended to treat such > >>>> support as experimental." > >>> What ambiguity "User agents **may** apply CSS properties to these > >>> elements"! > >> How is it ambiguous? I can only think of one thing that it means. If I > >> invite you to a party and you ask me what you should wear, and I reply > >> that you can wear whatever you want, do you think the word "ambiguous" > >> correctly describes my response? > > > A party invitation and a technical specification are two entirely > > different things. > > Stating the obvious fact that the things being compared in an analogy > are different doesn't defeat the analogy. EVERY analogy compares things > that are different in some way. Otherwise, the only valid analogy in the > world would be the trivial one that compares a thing to itself. The analogy is invalid because the standards of specificity are so wildy different when writing a formal document and a party invitation. > > >>> How did that get interpretted as, user agents MAY apply > >>> SOME but not necessarly ALL css properties? > >> Since it doesn't say, "the agent must apply none or all", there is no > >> basis for not understanding it to be granting this leeway to the user agent. > > > Exactly, since it doesn't say, all we can say is... it doesn't say! > > Which is why things are such a mess. > > It specifies very, very clearly that in the case of form controls the > user agent can do what it wants. What part of that are you finding unclear? Crystal, I'm just saying it's a bad thing that it's left unspecified, fair enough leave it optional. But not to say which attributes are optional has lead to the mess. Do a google for "style input css" to see what I mean.
From: Harlan Messinger on 15 Dec 2009 13:18 Mark Smith wrote: > On Dec 15, 4:54 pm, Harlan Messinger > <hmessinger.removet...(a)comcast.net> wrote: >> Mark Smith wrote: >>> On Dec 15, 3:51 pm, Harlan Messinger >>> <hmessinger.removet...(a)comcast.net> wrote: >>>> Mark Smith wrote: >>>>> On Dec 15, 3:15 pm, Harlan Messinger >>>>> <hmessinger.removet...(a)comcast.net> wrote: >>>>>> Mark Smith wrote: >>>>>>> On Dec 15, 2:33 pm, Harlan Messinger >>>>>>> <hmessinger.removet...(a)comcast.net> wrote: >>>>>>>> Mark Smith wrote: >>>>>>>>> On Dec 15, 1:19 pm, Harlan Messinger >>>>>>>>> <hmessinger.removet...(a)comcast.net> wrote: >>>>>>>>>> Mark Smith wrote: >>>>>>>>>>> On Dec 11, 1:06 pm, Harlan Messinger >>>>>>>>>>> <hmessinger.removet...(a)comcast.net> wrote: >>>>>>>>>>>> David Mark wrote: >>>>>>>>>>>>> On Dec 7, 6:54 am, Stefan Weiss <krewech...(a)gmail.com> wrote: >>>>>>>>>>>>>> On 07/12/09 11:50, Mark Smith wrote: >>>>>>>>>>>>>>> Oh, and for anyone else that is interested, I found an option 5. Ajax >>>>>>>>>>>>>>> uploads seem to be triggerable from script: >>>>>>>>>>>>>>> http://valums.com/wp-content/uploads/ajax-upload/demo-jquery.htm >>>>>>>>>>>>>> Did you look at how this was actually implemented? Apart from requiring >>>>>>>>>>>>>> JQuery, that demo page has file upload fields with opacity:0 overlayed >>>>>>>>>>>>>> above its buttons and links. I'd say this qualifies as >>>>>>>>>>>>>> | #3 Use some hacky CSS and overlays to style the file picker. >>>>>>>>>>>>> Yes. Most Web developers (or "designers") want everything to look >>>>>>>>>>>>> exactly the way they want it to look and never mind what the user >>>>>>>>>>>>> agent thinks. CSS "resets", brittle hacks, anything goes if it makes >>>>>>>>>>>>> it look exactly the same in IE, FF and Safari. It's backwards as the >>>>>>>>>>>>> developers of the user agents probably had a good idea of what sort of >>>>>>>>>>>>> default style would work best for inputs (buttons particularly). >>>>>>>>>>>> Imagine if every song you downloaded were to impose its producer's own >>>>>>>>>>>> conception of how music player controls should look on your music >>>>>>>>>>>> player, or if the display of the volume control bar on your TV screen >>>>>>>>>>>> depended on what channel or program you were watching. Perhaps a station >>>>>>>>>>>> broadcasting a slasher film would want your volume control display to >>>>>>>>>>>> look like it was dripping with blood. Wouldn't that be awesome? (being >>>>>>>>>>>> ironic) >>>>>>>>>>> I think the anology needs taken one step further to reflect where we >>>>>>>>>>> are currently with web standards. >>>>>>>>>>> Imagine if every song you downloaded sounded different on every type >>>>>>>>>>> of player - not how the musician intended. Wouldn't that be awesome? :) >>>>>>>>>> Music does sound different depending on the player and device. The music >>>>>>>>>> coming out of my Treo sounds very different from the sound coming out of >>>>>>>>>> my Toshiba Satellite's built-in speakers, and different again from the >>>>>>>>>> sound that comes out of my Onkyo tuner through my five KLM speakers. In >>>>>>>>>> addition, the sound coming out of my Onkyo can sound "multidimensional", >>>>>>>>>> and I can apply MY choice of sound distribution, and the musicians can't >>>>>>>>>> do a damn thing about it. >>>>>>>>> Type of speaker, distribution, sound levels, post processing effects >>>>>>>>> etc are analogous to the screen type, browser zoom, window size >>>>>>>>> controls etc, i.e. they are under the user control and can override >>>>>>>>> the defaults (if they wish). >>>>>>>>> Playlist management and navigation controls are analogous to the >>>>>>>>> browser address bar, back forward and history, i.e. nothing to do with >>>>>>>>> the content provider. >>>>>>>>> Elements on a web page however are like the instruments in music. >>>>>>>>> Having css styles applied to some elements on some browsers but not >>>>>>>>> others is like having a cd player that (without being asked) replaces >>>>>>>>> all percussion instruments on a track with a crappy sounding keyboard >>>>>>>>> synthesiser! (It's a mess and the standards need fixed). >>>>>>>> Your notion that the same considerations apply uniformly to anything >>>>>>>> that is part of the web page is flawed. >>>>>>> I didn't start the analogy. >>>>>>>> Form controls are user interface >>>>>>>> devices, regardless of the fact that they are on the page rather than >>>>>>>> built into the browser, and therefore there are considerations that >>>>>>>> apply to them independently of those that apply to lists and tables. >>>>>>> If that's the case, the standards still need fixed to specify that it >>>>>>> is up to the agent. >>>>>> It can't be fixed to specify that because it already specifies that: >>>>>> http://www.w3.org/TR/CSS21/conform.html#conformance >>>>>> "CSS 2.1 does not define which properties apply to form controls and >>>>>> frames, or how CSS can be used to style them. User agents may apply CSS >>>>>> properties to these elements. Authors are recommended to treat such >>>>>> support as experimental." >>>>> What ambiguity "User agents **may** apply CSS properties to these >>>>> elements"! >>>> How is it ambiguous? I can only think of one thing that it means. If I >>>> invite you to a party and you ask me what you should wear, and I reply >>>> that you can wear whatever you want, do you think the word "ambiguous" >>>> correctly describes my response? >>> A party invitation and a technical specification are two entirely >>> different things. >> Stating the obvious fact that the things being compared in an analogy >> are different doesn't defeat the analogy. EVERY analogy compares things >> that are different in some way. Otherwise, the only valid analogy in the >> world would be the trivial one that compares a thing to itself. > > The analogy is invalid because the standards of specificity are so > wildy different when writing a formal document and a party invitation. Why? Where did you get the idea that a specification can, or should, only have mandatory provisions, or apply a given requirement in exactly the same way to every single thing that the specification governs? You are under the false impression that some sort of constraint exists regarding what specifications may state. >>>>> How did that get interpretted as, user agents MAY apply >>>>> SOME but not necessarly ALL css properties? >>>> Since it doesn't say, "the agent must apply none or all", there is no >>>> basis for not understanding it to be granting this leeway to the user agent. >>> Exactly, since it doesn't say, all we can say is... it doesn't say! >>> Which is why things are such a mess. >> It specifies very, very clearly that in the case of form controls the >> user agent can do what it wants. What part of that are you finding unclear? > > Crystal, I'm just saying it's a bad thing that it's left unspecified, > fair enough leave it optional. But not to say which attributes are > optional has lead to the mess. Do a google for "style input css" to > see what I mean. It says user agents don't have to apply styles to form controls. So don't expect user agents to apply styles to form controls. You can try it if you want to, but don't rely on it happening. How is this a "mess"?
From: Mark Smith on 16 Dec 2009 04:05 On Dec 15, 6:18 pm, Harlan Messinger <hmessinger.removet...(a)comcast.net> wrote: > Mark Smith wrote: > > On Dec 15, 4:54 pm, Harlan Messinger > > <hmessinger.removet...(a)comcast.net> wrote: > >> Mark Smith wrote: > >>> On Dec 15, 3:51 pm, Harlan Messinger > >>> <hmessinger.removet...(a)comcast.net> wrote: > >>>> Mark Smith wrote: > >>>>> On Dec 15, 3:15 pm, Harlan Messinger > >>>>> <hmessinger.removet...(a)comcast.net> wrote: > >>>>>> Mark Smith wrote: > >>>>>>> On Dec 15, 2:33 pm, Harlan Messinger > >>>>>>> <hmessinger.removet...(a)comcast.net> wrote: > >>>>>>>> Mark Smith wrote: > >>>>>>>>> On Dec 15, 1:19 pm, Harlan Messinger > >>>>>>>>> <hmessinger.removet...(a)comcast.net> wrote: > >>>>>>>>>> Mark Smith wrote: > >>>>>>>>>>> On Dec 11, 1:06 pm, Harlan Messinger > >>>>>>>>>>> <hmessinger.removet...(a)comcast.net> wrote: > >>>>>>>>>>>> David Mark wrote: > >>>>>>>>>>>>> On Dec 7, 6:54 am, Stefan Weiss <krewech...(a)gmail.com> wrote: > >>>>>>>>>>>>>> On 07/12/09 11:50, Mark Smith wrote: > >>>>>>>>>>>>>>> Oh, and for anyone else that is interested, I found an option 5. Ajax > >>>>>>>>>>>>>>> uploads seem to be triggerable from script: > >>>>>>>>>>>>>>>http://valums.com/wp-content/uploads/ajax-upload/demo-jquery.htm > >>>>>>>>>>>>>> Did you look at how this was actually implemented? Apart from requiring > >>>>>>>>>>>>>> JQuery, that demo page has file upload fields with opacity:0 overlayed > >>>>>>>>>>>>>> above its buttons and links. I'd say this qualifies as > >>>>>>>>>>>>>> | #3 Use some hacky CSS and overlays to style the file picker. > >>>>>>>>>>>>> Yes. Most Web developers (or "designers") want everything to look > >>>>>>>>>>>>> exactly the way they want it to look and never mind what the user > >>>>>>>>>>>>> agent thinks. CSS "resets", brittle hacks, anything goes if it makes > >>>>>>>>>>>>> it look exactly the same in IE, FF and Safari. It's backwards as the > >>>>>>>>>>>>> developers of the user agents probably had a good idea of what sort of > >>>>>>>>>>>>> default style would work best for inputs (buttons particularly). > >>>>>>>>>>>> Imagine if every song you downloaded were to impose its producer's own > >>>>>>>>>>>> conception of how music player controls should look on your music > >>>>>>>>>>>> player, or if the display of the volume control bar on your TV screen > >>>>>>>>>>>> depended on what channel or program you were watching. Perhaps a station > >>>>>>>>>>>> broadcasting a slasher film would want your volume control display to > >>>>>>>>>>>> look like it was dripping with blood. Wouldn't that be awesome? (being > >>>>>>>>>>>> ironic) > >>>>>>>>>>> I think the anology needs taken one step further to reflect where we > >>>>>>>>>>> are currently with web standards. > >>>>>>>>>>> Imagine if every song you downloaded sounded different on every type > >>>>>>>>>>> of player - not how the musician intended. Wouldn't that be awesome? :) > >>>>>>>>>> Music does sound different depending on the player and device. The music > >>>>>>>>>> coming out of my Treo sounds very different from the sound coming out of > >>>>>>>>>> my Toshiba Satellite's built-in speakers, and different again from the > >>>>>>>>>> sound that comes out of my Onkyo tuner through my five KLM speakers. In > >>>>>>>>>> addition, the sound coming out of my Onkyo can sound "multidimensional", > >>>>>>>>>> and I can apply MY choice of sound distribution, and the musicians can't > >>>>>>>>>> do a damn thing about it. > >>>>>>>>> Type of speaker, distribution, sound levels, post processing effects > >>>>>>>>> etc are analogous to the screen type, browser zoom, window size > >>>>>>>>> controls etc, i.e. they are under the user control and can override > >>>>>>>>> the defaults (if they wish). > >>>>>>>>> Playlist management and navigation controls are analogous to the > >>>>>>>>> browser address bar, back forward and history, i.e. nothing to do with > >>>>>>>>> the content provider. > >>>>>>>>> Elements on a web page however are like the instruments in music. > >>>>>>>>> Having css styles applied to some elements on some browsers but not > >>>>>>>>> others is like having a cd player that (without being asked) replaces > >>>>>>>>> all percussion instruments on a track with a crappy sounding keyboard > >>>>>>>>> synthesiser! (It's a mess and the standards need fixed). > >>>>>>>> Your notion that the same considerations apply uniformly to anything > >>>>>>>> that is part of the web page is flawed. > >>>>>>> I didn't start the analogy. > >>>>>>>> Form controls are user interface > >>>>>>>> devices, regardless of the fact that they are on the page rather than > >>>>>>>> built into the browser, and therefore there are considerations that > >>>>>>>> apply to them independently of those that apply to lists and tables. > >>>>>>> If that's the case, the standards still need fixed to specify that it > >>>>>>> is up to the agent. > >>>>>> It can't be fixed to specify that because it already specifies that: > >>>>>>http://www.w3.org/TR/CSS21/conform.html#conformance > >>>>>> "CSS 2.1 does not define which properties apply to form controls and > >>>>>> frames, or how CSS can be used to style them. User agents may apply CSS > >>>>>> properties to these elements. Authors are recommended to treat such > >>>>>> support as experimental." > >>>>> What ambiguity "User agents **may** apply CSS properties to these > >>>>> elements"! > >>>> How is it ambiguous? I can only think of one thing that it means. If I > >>>> invite you to a party and you ask me what you should wear, and I reply > >>>> that you can wear whatever you want, do you think the word "ambiguous" > >>>> correctly describes my response? > >>> A party invitation and a technical specification are two entirely > >>> different things. > >> Stating the obvious fact that the things being compared in an analogy > >> are different doesn't defeat the analogy. EVERY analogy compares things > >> that are different in some way. Otherwise, the only valid analogy in the > >> world would be the trivial one that compares a thing to itself. > > > The analogy is invalid because the standards of specificity are so > > wildy different when writing a formal document and a party invitation. > > Why? Where did you get the idea that a specification can, or should, > only have mandatory provisions, or apply a given requirement in exactly > the same way to every single thing that the specification governs? You > are under the false impression that some sort of constraint exists > regarding what specifications may state. "A specification is an explicit set of requirements to be satisfied by a material, product, or service." http://en.wikipedia.org/wiki/Specification_(technical_standard) > >>>>> How did that get interpretted as, user agents MAY apply > >>>>> SOME but not necessarly ALL css properties? > >>>> Since it doesn't say, "the agent must apply none or all", there is no > >>>> basis for not understanding it to be granting this leeway to the user agent. > >>> Exactly, since it doesn't say, all we can say is... it doesn't say! > >>> Which is why things are such a mess. > >> It specifies very, very clearly that in the case of form controls the > >> user agent can do what it wants. What part of that are you finding unclear? > > > Crystal, I'm just saying it's a bad thing that it's left unspecified, > > fair enough leave it optional. But not to say which attributes are > > optional has lead to the mess. Do a google for "style input css" to > > see what I mean. > > It says user agents don't have to apply styles to form controls. So > don't expect user agents to apply styles to form controls. You can try > it if you want to, but don't rely on it happening. How is this a "mess"? Because dum dum, it's there so expect designers to *try* and use it. And expect it to break because it's not defined *explicitly* how a browser should handle it in the spec.
From: Harlan Messinger on 16 Dec 2009 07:46 Mark Smith wrote: > On Dec 15, 6:18 pm, Harlan Messinger > <hmessinger.removet...(a)comcast.net> wrote: >> Mark Smith wrote: >>> On Dec 15, 4:54 pm, Harlan Messinger >>> <hmessinger.removet...(a)comcast.net> wrote: >>>> Mark Smith wrote: >>>>> On Dec 15, 3:51 pm, Harlan Messinger >>>>> <hmessinger.removet...(a)comcast.net> wrote: >>>>>> Mark Smith wrote: >>>>>>> On Dec 15, 3:15 pm, Harlan Messinger >>>>>>> <hmessinger.removet...(a)comcast.net> wrote: >>>>>>>> Mark Smith wrote: >>>>>>>>> On Dec 15, 2:33 pm, Harlan Messinger >>>>>>>>> <hmessinger.removet...(a)comcast.net> wrote: >>>>>>>>>> Mark Smith wrote: >>>>>>>>>>> Playlist management and navigation controls are analogous to the >>>>>>>>>>> browser address bar, back forward and history, i.e. nothing to do with >>>>>>>>>>> the content provider. >>>>>>>>>>> Elements on a web page however are like the instruments in music. >>>>>>>>>>> Having css styles applied to some elements on some browsers but not >>>>>>>>>>> others is like having a cd player that (without being asked) replaces >>>>>>>>>>> all percussion instruments on a track with a crappy sounding keyboard >>>>>>>>>>> synthesiser! (It's a mess and the standards need fixed). >>>>>>>>>> Your notion that the same considerations apply uniformly to anything >>>>>>>>>> that is part of the web page is flawed. >>>>>>>>> I didn't start the analogy. >>>>>>>>>> Form controls are user interface >>>>>>>>>> devices, regardless of the fact that they are on the page rather than >>>>>>>>>> built into the browser, and therefore there are considerations that >>>>>>>>>> apply to them independently of those that apply to lists and tables. >>>>>>>>> If that's the case, the standards still need fixed to specify that it >>>>>>>>> is up to the agent. >>>>>>>> It can't be fixed to specify that because it already specifies that: >>>>>>>> http://www.w3.org/TR/CSS21/conform.html#conformance >>>>>>>> "CSS 2.1 does not define which properties apply to form controls and >>>>>>>> frames, or how CSS can be used to style them. User agents may apply CSS >>>>>>>> properties to these elements. Authors are recommended to treat such >>>>>>>> support as experimental." >>>>>>> What ambiguity "User agents **may** apply CSS properties to these >>>>>>> elements"! >>>>>> How is it ambiguous? I can only think of one thing that it means. If I >>>>>> invite you to a party and you ask me what you should wear, and I reply >>>>>> that you can wear whatever you want, do you think the word "ambiguous" >>>>>> correctly describes my response? >>>>> A party invitation and a technical specification are two entirely >>>>> different things. >>>> Stating the obvious fact that the things being compared in an analogy >>>> are different doesn't defeat the analogy. EVERY analogy compares things >>>> that are different in some way. Otherwise, the only valid analogy in the >>>> world would be the trivial one that compares a thing to itself. >>> The analogy is invalid because the standards of specificity are so >>> wildy different when writing a formal document and a party invitation. >> Why? Where did you get the idea that a specification can, or should, >> only have mandatory provisions, or apply a given requirement in exactly >> the same way to every single thing that the specification governs? You >> are under the false impression that some sort of constraint exists >> regarding what specifications may state. > > "A specification is an explicit set of requirements to be satisfied by > a material, product, or service." > http://en.wikipedia.org/wiki/Specification_(technical_standard) > Ignoring the fact that Wikipedia is not the master specification for how everything in the world works, this does not mean that a specification can only contain *absolutely required provisions*. A specification specifies how a system is supposed to work. That includes specifying what aspects must be chosen from among a set of options, and which items are optional altogether (while possibly stating that, if they ARE used, they must be used in such-and-such a way). >>>>>>> How did that get interpretted as, user agents MAY apply >>>>>>> SOME but not necessarly ALL css properties? >>>>>> Since it doesn't say, "the agent must apply none or all", there is no >>>>>> basis for not understanding it to be granting this leeway to the user agent. >>>>> Exactly, since it doesn't say, all we can say is... it doesn't say! >>>>> Which is why things are such a mess. >>>> It specifies very, very clearly that in the case of form controls the >>>> user agent can do what it wants. What part of that are you finding unclear? >>> Crystal, I'm just saying it's a bad thing that it's left unspecified, >>> fair enough leave it optional. But not to say which attributes are >>> optional has lead to the mess. Do a google for "style input css" to >>> see what I mean. >> It says user agents don't have to apply styles to form controls. So >> don't expect user agents to apply styles to form controls. You can try >> it if you want to, but don't rely on it happening. How is this a "mess"? > > Because dum dum, <plonk/> > it's there so expect designers to *try* and use it. > And expect it to break because it's not defined *explicitly* how a > browser should handle it in the spec.
From: Mark Smith on 16 Dec 2009 08:35
On Dec 16, 12:46 pm, Harlan Messinger <hmessinger.removet...(a)comcast.net> wrote: > Mark Smith wrote: > > On Dec 15, 6:18 pm, Harlan Messinger > > <hmessinger.removet...(a)comcast.net> wrote: > >> Mark Smith wrote: > >>> On Dec 15, 4:54 pm, Harlan Messinger > >>> <hmessinger.removet...(a)comcast.net> wrote: > >>>> Mark Smith wrote: > >>>>> On Dec 15, 3:51 pm, Harlan Messinger > >>>>> <hmessinger.removet...(a)comcast.net> wrote: > >>>>>> Mark Smith wrote: > >>>>>>> On Dec 15, 3:15 pm, Harlan Messinger > >>>>>>> <hmessinger.removet...(a)comcast.net> wrote: > >>>>>>>> Mark Smith wrote: > >>>>>>>>> On Dec 15, 2:33 pm, Harlan Messinger > >>>>>>>>> <hmessinger.removet...(a)comcast.net> wrote: > >>>>>>>>>> Mark Smith wrote: > >>>>>>>>>>> Playlist management and navigation controls are analogous to the > >>>>>>>>>>> browser address bar, back forward and history, i.e. nothing to do with > >>>>>>>>>>> the content provider. > >>>>>>>>>>> Elements on a web page however are like the instruments in music. > >>>>>>>>>>> Having css styles applied to some elements on some browsers but not > >>>>>>>>>>> others is like having a cd player that (without being asked) replaces > >>>>>>>>>>> all percussion instruments on a track with a crappy sounding keyboard > >>>>>>>>>>> synthesiser! (It's a mess and the standards need fixed). > >>>>>>>>>> Your notion that the same considerations apply uniformly to anything > >>>>>>>>>> that is part of the web page is flawed. > >>>>>>>>> I didn't start the analogy. > >>>>>>>>>> Form controls are user interface > >>>>>>>>>> devices, regardless of the fact that they are on the page rather than > >>>>>>>>>> built into the browser, and therefore there are considerations that > >>>>>>>>>> apply to them independently of those that apply to lists and tables. > >>>>>>>>> If that's the case, the standards still need fixed to specify that it > >>>>>>>>> is up to the agent. > >>>>>>>> It can't be fixed to specify that because it already specifies that: > >>>>>>>>http://www.w3.org/TR/CSS21/conform.html#conformance > >>>>>>>> "CSS 2.1 does not define which properties apply to form controls and > >>>>>>>> frames, or how CSS can be used to style them. User agents may apply CSS > >>>>>>>> properties to these elements. Authors are recommended to treat such > >>>>>>>> support as experimental." > >>>>>>> What ambiguity "User agents **may** apply CSS properties to these > >>>>>>> elements"! > >>>>>> How is it ambiguous? I can only think of one thing that it means. If I > >>>>>> invite you to a party and you ask me what you should wear, and I reply > >>>>>> that you can wear whatever you want, do you think the word "ambiguous" > >>>>>> correctly describes my response? > >>>>> A party invitation and a technical specification are two entirely > >>>>> different things. > >>>> Stating the obvious fact that the things being compared in an analogy > >>>> are different doesn't defeat the analogy. EVERY analogy compares things > >>>> that are different in some way. Otherwise, the only valid analogy in the > >>>> world would be the trivial one that compares a thing to itself. > >>> The analogy is invalid because the standards of specificity are so > >>> wildy different when writing a formal document and a party invitation.. > >> Why? Where did you get the idea that a specification can, or should, > >> only have mandatory provisions, or apply a given requirement in exactly > >> the same way to every single thing that the specification governs? You > >> are under the false impression that some sort of constraint exists > >> regarding what specifications may state. > > > "A specification is an explicit set of requirements to be satisfied by > > a material, product, or service." > >http://en.wikipedia.org/wiki/Specification_(technical_standard) > > Ignoring the fact that Wikipedia is not the master specification for how > everything in the world works, this does not mean that a specification > can only contain *absolutely required provisions*. A specification > specifies how a system is supposed to work. That includes specifying > what aspects must be chosen from among a set of options, and which items > are optional altogether (while possibly stating that, if they ARE used, > they must be used in such-and-such a way). > Just because something can be done, does not imply that it *should* be done. Leaving it open like that has manifested itself in many problems, most of which are covered in this thread. |