On Wed, Jan 6, 2010 at 12:40 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> I could live with that, if it's as fast as JavaScript regexp processing.
> Simple regexp and literals run pretty fast, don't they? And dynamic element
> changes also require rematching. I don't think I'd want it to run the
> matching every second as I typed into editable HTML.
>
That's exactly what a browser has to do.
No way. Talk about idealistic goals that cant be reached! I should have the
> content/markup author tell the UA where all the numbers are, just because I
> want to style them differently? I should insist on a separate class for
> every phone number that matches a particular one that I might be interested
> in styling? What HTML tag do I use for a ">" that represents another level
> of breadcrumbs? These are all things that I cannot reasonably expect to be
> in the markup, but that I may want to style. There are already many places
> where authors are adding extra spans in the HTML just to get a
> presentational effect, and I think we should provide ways to alleviate that
> where we can.
>
Sure, but that set of examples aren't just presentational effects, they have
semantic meaning. Maybe not expressible in HTML directly, but there's
nothing "wrong" with adding classes for them.
CSS needs some cooperation from the document author. Even using
::text("Example \d: *\n"), the author has to make sure to put the right
number of spaces in, which is arguably harder to get right than wrapping the
text in a span with a class.
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
Received on Wednesday, 6 January 2010 00:00:12 UTC