Re: [css3-regions] elements vs. selectors

On Sun, Apr 3, 2011 at 3:06 AM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> I think there should be a dedicated HTML element to represent a "region".
>
> I know it sounds like I am out of my mind. And it is on the opposite end of spectrum from "slots" (as I understand them), but let me explain.
>
> We are going to bring to the web another concept of established typographic tradition - linked text boxes. It's a set of containers, possibly of irregular shapes, that text of a story can flow through, and you can follow the story by moving your eyes from one box to another, just like flipping pages.

I strongly disagree.  Flowing between regions is dependent on the
layout of the page, and the layout of the page can easily change
dynamically, based on Media Queries and similar.  HTML can't be
generated or changed by anything compatible with MQ.

In my opinion, flows should definitely work across pseudo-elements.
The fact that they don't have good OM support just means we need to
fix that.

~TJ


> So we need a definition for something like this......
>
> A) Object to represent a "story" (not a common technical term, but I like to use it to refer to represent some amount of text that has a beginning, an end and a linear progression in between).
>
> -- It has content (which might be some text that it literally contains,
>   or perhaps it could be a link to a file).
> -- It has no rendering but it can provide content stream for containers
>   that are willing to render it.
> -- It has a way to be identified (for example a name).
> -- I may need OM to read and/or modify the content
>
> B) Object to represent one of the linked boxes that display the content of a story.
>
> -- It needs a way to refer to the story (story object that is).
> -- Given a size, it must be able to render as much content that fits
>   in it, and let another box continue.
> -- It may need ability to change appearance of content when it flows
>   through it (such as provide background or change text properties)
> -- It may need OM to determine what portion of content exactly is in it.
>
> Imagine for a moment that we are free to create HTML element or CSS properties at will, we just need to decide what we want. What would it be?
>
> Why not something like this?
>
> A)  <story src="url" flow="flowname">
>        fallback content that is used as source if there is no 'src'
>        property or if source url fails to load
>    </story>
>
>
>    Very similar to <iframe> or <object> (and takes advantage of iframe
>    security boundaries), but is never rendered itself.
>
> B)  <page flow="flowname" />
>
>    "page" as a virtual page of content that is flown through these boxes.
>
>    Kind of like iframe for layout -- content has no effect on its
>    container size. It cannot have content of its own.
>    Content shown in the box is part of a story, possibly continued
>    from another box.
>
> HTML is about semantic elements, and (A) sounds pretty semantic. It is pure data. Ought to be an element. (B) is right on the boundary between content and view -- it shows content from elsewhere. Which is about as far as it gets from a style -- its own content is not getting styled, it is getting dumped...
>
> OK, back to reality. I asked around, and I hear it is difficult and generally not a good idea to add elements to HTML. I am not sure I agree with reasoning, but let's suppose a new element is not an option. What else?
>
> Let's look for second best.
>
> (A) <object> looks the closest. It has fallback to inline content. And it has not default rendering. Would be like this:
>
>        <object data="foo.html" flow="flowname">
>
> Not very intuitive though... <iframe>, <link> are other options. <div> is possible but not great, as it doesn't naturally redirect to a file.
>
> (B) This is not looking good. Basically the choice is between
>        <iframe> - because it already ignores its content. But it has "src"
>                 which is supposed to be loaded - and ignored too???
>        <div> (or any other non-replaced element) -  no "src" to worry about,
>                 but we'll have to discard the content which is unusual.
>      <embed> - another element with no content, but very non-intuitive.
>      ::slot - a pseudo-element created from CSS, no inline content to ignore.
>                 but also no OM (as it is not an element)
>
> Given the choices, I think <iframe> as flow source and <div> as flow container are lesser evil, but I still believe definition for linked flow containers belongs to HTML - in a perfect world.
>
> (attached: a simple example with a few syntax options, from new element to ::slot)
>
> What do you think?
> Alex
>

Received on Tuesday, 12 April 2011 17:21:04 UTC