On Mon, Jun 15, 2009 at 2:14 PM, Aryeh Gregor
<simetrical+...@gmail.com<simetrical%2b...@gmail.com>
> wrote:
> On Mon, Jun 15, 2009 at 4:26 PM, Thomas Powell<tpow...@gmail.com> wrote:
> > Proposing <nostyle> in the spirit of <noscript>
> >
> > Examples
> > --------
> > 1) Head Usage
> > <nostyle>
> > <meta http-equiv="Refresh" content="0;url=/errors/stylerequired.html">
> > </nostyle>
> >
> > 2) Body Usage
> > <nostyle>
> > <h2>Warning: Styles required for correct rendering</h2>
> > </nostyle>
>
> The reason that <noscript> worked is because (IIRC) it was introduced
> at the same time as <script>. All browsers that supported <script>
> also supported <noscript>. <nostyle> would cause all legacy user
> agents to render the content even if they supported styles just fine.
>
Yes in the absence of our time machine it seems a bit late doesn't it.
>
> > And yes while that is true and for many situations will work fine, there
> are
> > other cases you won't and you can get a sloppy or even bad results
> because
> > of rendering engine paths. For example, because style is not applied
> until
> > later you have an issue here
> >
> > <h2 class="nostyle"><img src="error.gif">Warning: Styles required for
> > correct rendering</h2>
> >
> > The network request happens regardless of situation no assuming images
> on.
>
> That doesn't seem like a very serious issue. Just don't use images if
> you care that much. A large percentage of non-CSS browsers are
> probably text-based anyway.
>
It isn't but hints at what the motivation was from a real world request (see
below)
>
> > For example, using the content property can be somewhat troubling if
> > style is removed. For example, consider what happens if you are putting
> in
> > field required indicators
> > input[type=text].required:before {content: " (*) "}
>
> This should just use HTML5's required attribute instead of a class:
>
> http://dev.w3.org/html5/spec/Overview.html#the-required-attribute
>
> Agreed that is the case, this is more documenting the usage of designers
not that there isn't an HTML 5 appropriate solution.
Conformant browsers should make it clear to the user that the field is
> required even if styles are disabled.
>
yes they should.
>
> > or for offsite links
> > a[href^="http://"]:after {content:' ( Offsite Link )';}
>
> This is non-essential info, and every browser I've heard of exposes it
> anyway (e.g., by hovering over the link and looking in the lower
> left).
>
> > or any other dynamic insert this way.
>
> Do you have any other examples where this is a significant issue?
> Those two don't seem like a big deal to me, honestly, even if it were
> logistically possible to get <nostyle> supported widely enough to be
> useful.
Those were just examples of more valid uses of content actually. Of course
as I mentioned below people can abuse this property and then it does become
a big deal. But dynamically having content jam in all sorts of stuff
client-side seems wrong-headed so I certainly don't suggest codifying bad
practices though mitigating them somehow seems appropriate.
>
> If CSS is necessary for a site to operate, it's probably being
> misused. If an author is misusing CSS this badly, it's not clear to
> me why they could be expected to reliably use <nostyle>. The contents
> of <nostyle> also don't make a difference to almost anyone, so authors
> who use it won't really understand the purpose it serves and it will
> probably be misused more often than used.
>
You may be quite right. Understand my purpose of proposing this was mostly
due to some contrivances to determine style and no-style support for an
effort which is very contingency concerned. The solution that was adopted
using scripting, server-side logging particularly triggered by image
requests from background-image values or their absence, etc. can figure all
cases but it was a mess and thus the "why not have a <nostyle> wouldn't life
be easier" So from where you sit yes it is not that important likely, from
having to wrestle with it I would have loved to have an easy solution.
Anyway I will say that there is a
bit of symmetry of having on/off cases for all the various client-side
technologies
(img, script, object,
etc.), but I see that the off aspect of style could simply be thought
of as the markup itself and that is
certainly fine it has worked for most so far.
