File input problem
in [CSS]
|
Prev: Help with a Table Wanted
Next: background shorthand
From: Harlan Messinger on 15 Dec 2009 10:15 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." > Rather than this halfway house where we currently have elements that > are partly styled by css and partly by the browser. To make things > worse, which parts that CAN be styled are also different between > browsers.
From: Mark Smith on 15 Dec 2009 10:37 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 did that get interpretted as, user agents MAY apply SOME but not necessarly ALL css properties? So, the consensus here is that we should not be styling input elements, why even 'experiment' with the feature? The support is kind of, sort of there in most browsers. Most designers will try and use it, look at the rest of the web. Do you not think it would be better if the standard said - such elements are NOT to be styled, or if they are to be styled at least use ALL of the properties, rather than leave such a gaping hole for both designers and users to get into trouble with? I can't believe that that is the official line!
From: Harlan Messinger on 15 Dec 2009 10:51 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? > 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. > So, the consensus here is that we should not be styling input > elements, why even 'experiment' with the feature? I think a more accurate description of the consensus is that the *inability* to style these elements in a given browser is not an infringement of a God-given right, and might actually be reasonable. > The support is kind of, sort of there in most browsers. Most designers > will try and use it, look at the rest of the web. > > Do you not think it would be better if the standard said - such > elements are NOT to be styled, or if they are to be styled at least > use ALL of the properties, rather than leave such a gaping hole for > both designers and users to get into trouble with? > > I can't believe that that is the official line! If I invite you to a party, I'll be sure to tell you exactly what you must wear, since I gather that you would consider me to be remarkably wishy-washy otherwise.
From: Mark Smith on 15 Dec 2009 11:31 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. > > > 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.
From: Harlan Messinger on 15 Dec 2009 11:54
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. >>> 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? |