We're using SSE as a reliable Server -> Browser streaming mechanism where
the server maintains a message queue per user connection. The server needs
to buffer all messages until it receives an acknowledgment for a given
message (ACK). The server sometimes needs to indicate to the Browser that
the m
On Mon, 21 Apr 2008 00:26:46 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:
I've also made the title="" attribute on
required, [...]
There are legitimate reasons to not fill up the title attribute of
. Or should be disallowed in these situations?
I've disallowed it.
What's the point? The
On 21/04/2008, Smylers <[EMAIL PROTECTED]> wrote:
> Can you link to examples of such webpages, which have elements
> without title attibutes? What does that mark-up currently achieve?
Out of 130K pages from dmoz.org, I see 592 using elements, and
36 of those using it at least once with no titl
Jim Jewett writes:
> It isn't clear why the validity constraints of abbr need to be
> tightened.
HTML 5 didn't start as HTML 4, so it isn't so much a case of
"tightening" HTML 4 as having to provide a reason to include things into
HTML 5 -- including those defined in HTML 4.
> The use cases are
Nicholas Shanks writes:
> Ian, I think you have made a mistake.
The message of Ian's you replied to covered several different things (as
indicated by the subject line) and you didn't quote any of it. Could
you be more specific on which bit you consider to be a mistake?
> We need to go through t
Ian, I think you have made a mistake.
We need to go through this more methodically before making a decision.
I hope the following aids matters.
First, lets think about who will use abbreviations and why they need
them, second, think about where the information could come from.
Situations
Patrick H. Lauke writes:
> Smylers wrote:
>
> > Well it's very close to being useless. In that if browsers don't do
> > anything with some mark-up, there's no point in having it (and
> > indeed no incentive for authors to provide it).
>
> Assistive technology is certainly a valid use case here.
Aaron Boodman wrote:
On Wed, Apr 16, 2008 at 3:17 PM, Jonas Sicking <[EMAIL PROTECTED]> wrote:
Maciej Stachowiak wrote:
- Processing a reply synchronously is awkward in any case, since you need
a callback.
I'm not sure I follow this argument, I actually come to the opposite
conclusion.
Say th
On Mon, Apr 21, 2008 at 4:15 AM, Jens Meiert <[EMAIL PROTECTED]> wrote:
> > The point of is to expand the acronym, not to just mark up what
> is
> > an acryonym or abbreviation.
>
> Doesn't this claim that the general information that some text is an
> abbreviation (w/o an expanded form) is basic
Jens Meiert writes:
> > The point of is to expand the acronym, not to just mark up
> > what is an acryonym or abbreviation.
>
> Doesn't this claim that the general information that some text is an
> abbreviation (w/o an expanded form) is basically useless?
Well it's very close to being useless.
Ian Hickson wrote:
On Sat, 28 Apr 2007, Bill Mason wrote:
3) The back button is not considered reliable as a navigation aid if
target=_blank is not in use.
Can you elaborate on why this is?
I don't particularly believe that this is true. I made that statement in
accepting for the sake of ar
I haven't added any new markup for footnotes or end notes. Side notes
without callouts in the main flow are possible with .
For footnotes and end notes there have been a number of proposals, such
as the following (and variants on them):
text text note note text text
text text 1 text t
Shannon writes:
> Shannon wrote:
>
> What about this as a possible solution?
>
> >
> >
> >
> >
> >
> > I don't think this would raise any serious implementation issues as
> > the logic is quite simple;
>
> Smylers wrote:
>
> > What advantage does it have over Simon's proposal?
> >
> >
> The point of is to expand the acronym, not to just mark up what is
> an acryonym or abbreviation.
Doesn't this claim that the general information that some text is an
abbreviation (w/o an expanded form) is basically useless? And is
"ISS" not more useful since less ambiguous than "ISS"
(same abb
On Mon, 21 Apr 2008 08:48:06 +0200, Shannon <[EMAIL PROTECTED]> wrote:
Benjamin Hawkes-Lewis wrote:
I think you've misunderstand Simon's suggestion, which was:
Rating:
Note /all/ the img elements have alt attributes, the point is the
alternative text for the group is expressed by the firs
Benjamin Hawkes-Lewis wrote:
But whether we need a mechanism for denoting differing img elements
combine to form a single image is a very different question from
whether alt should be optional or required. You seem to be conflating
them.
How can or not be related to making alt optional?
Shannon wrote:
Benjamin Hawkes-Lewis wrote:
I think you've misunderstand Simon's suggestion, which was:
Rating:
Note /all/ the img elements have alt attributes, the point is the
alternative text for the group is expressed by the first alt
attribute. It's thus actually the same as the fallb
Benjamin Hawkes-Lewis wrote:
I think you've misunderstand Simon's suggestion, which was:
Rating:
Note /all/ the img elements have alt attributes, the point is the
alternative text for the group is expressed by the first alt
attribute. It's thus actually the same as the fallback you propose:
Shannon wrote:
Smylers wrote:
What advantage does it have over Simon's proposal?
Simon's suggestion has the obvious advantage that it already works with
current browsers.
Smylers
Simon's suggestion is no different from the original proposal, the idea
that alt can be optional on some images
19 matches
Mail list logo
