hat content. The whole
publication process becomes more managable. I think that's a benefit that
will be recognised.
--
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
be a quite an
undertaking to improve authoring tools, it is still much easier than to
succesfully preach to each and every webdesigner out there... I consider this
shift towards using HTML generators an opportunity to get closer to a
semantically rich and accessible Web.
--
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
At 02:19 +0100 UTC, on 2007-01-11, Håkon Wium Lie wrote:
> Also sprach Sander Tekelenburg:
>
> > FWIW, my feeling is that it would be best if there'd be a defined format
>for
> > hyphenation rules, and browsers would accept such description files [...]
>
> This
on browser authors. (Browsers
could of course still be shipped with such rulesets.)
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
At 14:42 +1300 UTC, on 2007-01-07, Matthew Paul Thomas wrote:
> On Jan 7, 2007, at 7:13 AM, Sander Tekelenburg wrote:
[...]
>> It's still entirely unclear to me *why* the cite attribute needs a
>> replacement. What is wrong with it?
>
> First, it's hard for UAs to
gt; Mostly to make the metadata more "visual".
It's still entirely unclear to me *why* the cite attribute needs a
replacement. What is wrong with it?
--
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
At 22:26 -0500 UTC, on 2007-01-02, Matthew Raymond wrote:
[...]
>Okay, how 'bout this:
>
> |
> |
> | rhubarb rhubarb rhubarb
> | [Nemo, Works, IV]
> |
> |
FWIW, I still cannot follow exactly what problem people are trying to solve
in this thread.
At 16:26 + UTC, on 2006-12-31, Benjamin Hawkes-Lewis wrote:
> Sander Tekelenburg wrote:
[...]
> I assumed Anne meant something like:
>
> rhubarb rhubarb rhubarb [Nemo,
> Works, IV]
Ah. Maybe, that's what he meant, yes. But I don't see how this offers any
advant
ual menu's "Show Reference" command. (I'm not fond of
'hover-dependancy' like this, but through CSS a more easily recognisable clue
can be added. For instance something like the dotted underline that has
become somewhat common, to indicate title attributes for abbr and acronym.)
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
At 16:13 + UTC, on 2006-12-08, Simon Pieters wrote:
> From: Sander Tekelenburg <[EMAIL PROTECTED]>
>>[...] But it still leaves the question whether
>>every browser will in fact be HTML5 compliant.
>
> They probably won't, at least for the next few years.
Right
At 02:42 +1100 UTC, on 2006-12-09, Lachlan Hunt wrote:
> Sander Tekelenburg wrote:
>> [...] errors that result in 'good' looking pages in Explorer, and
>> 'bad' in HTML5 browsers. Simply by producing code that they know will result
>> in 'bad&#
enrate problems when accessed with Safari, Mozilla/Firefox,
Opera, iCab, lynx, IE pre-6, braille and speech browsers, mobile browsers,
spiders, etc. (Especially if you consider more than just HTML. Think of
things like javascript-dependancy, Flash-dependancy, WindowsMedia-depencency,
and even CSS-dependancy.)
--
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
At 02:37 + UTC, on 2006-12-08, Ian Hickson wrote:
> On Fri, 8 Dec 2006, Sander Tekelenburg wrote:
[...]
>> <http://www.whatwg.org/specs/web-apps/current-work/#parsing> [...]
>>
>> "The error handling for parse errors is well-defined: user agents must
>&
At 01:22 + UTC, on 2006-12-08, Ian Hickson wrote:
> On Thu, 7 Dec 2006, Sander Tekelenburg wrote:
>> At 00:45 + UTC, on 2006-12-05, Ian Hickson wrote:
[...]
>> I'm still somewhat sceptical about the reality of this though, as it relies
>> on the author che
inst HTML5. I'm just trying to get a clear picture of just how
much of a difference HTML5 can actually mak; to what extend Ian's description
of what I labelled "guesswork" may actually become reality.
--
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
At 06:30 -0500 UTC, on 2006-12-05, Mike Schinkel wrote:
> Sander Tekelenburg wrote:
[...]
>>>> The tools need to be standard and compatible.
>>>I can't follow this. In what sense? Tidy is Tidy.
>>>AWPS authors can incorporate it into their product.
>>
riggers HTML5-compliant browsers to, as per the
HTML5 spec, stop processing the document, and have InternetExplorer present
such documents as if they're fine.
What then? Will every other browser really tell the user that it won't try to
interpret what the author might have meant?
--
At 20:46 + UTC, on 2006-12-04, Ian Hickson wrote:
> On Mon, 4 Dec 2006, Sander Tekelenburg wrote:
[...]
[ESP engines]
>> Surely you're not saying that HTML5 will define error handling for every
>> possible case a UA may run into?
>
> Yes. In fact, not only will
[I unintentionally sent my previous message off-list. Sorry about that. Am
moving this back to the list again. As there's nothing personal in it, I
assume that's OK.]
At 18:37 + UTC, on 2006-12-04, Ian Hickson wrote:
> On Mon, 4 Dec 2006, Sander Tekelenburg wrote:
[...]
At 00:48 -0500 UTC, on 2006-12-04, Mike Schinkel wrote:
> Sander Tekelenburg wrote:
[...]
> Forum posting is but one of many contexts. I daresay non-technical people
> who write blogs and wikis care about format, as do even forum posters.
[...]
> I think defining people in thes
re is no way HTML 5 can
define everything that people might possibly throw at the Web. To quote a
remark you made earlier: "(although how to ensure the clueless get a clue, I
have no suggestions.) So this option is not very likely to produce good
results."
--
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
ntational issue, so I'm not
that enthusiastic about calling it a element. Why not simply
? You can then allow the author to decide where in the page, or
in a group of pages, to place the element, and use CSS for the
presentational aspects. (You could allow the same with , but that
nam
if you add such a requirement to the HTML
5 spec, you'll need make sure that server authors are on your side.
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
that it requires a separate Web page, which would
exclude the possibility of presentating the annotation in the same page.
Perhaps an longdesc-like annotation element should therefore require an
anchor (pointing to an ID within the current page), not allow URLs that point
to external documents.
[
t browser
implementation poverty, not title attribute problems. Same for his arguments
for "footnotes".
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
of the Web... Just
not Flashy enough for most Web publishers ;))
[*] I have to admit I don't understand axis. The HTML 4.01 description of it
is way beyond rocket science to me. So thus far I've only used headers and
scope.
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
At 19:00 +0200 UTC, on 2006-08-24, Charles McCathieNevile wrote:
> On Thu, 24 Aug 2006 18:44:26 +0200, Sander Tekelenburg
> <[EMAIL PROTECTED]> wrote:
[...]
>> I imagine the quickest way to get an implementation would be in the form
>> of a Firefox plug-in.
>
> A
At 17:54 +0100 UTC, on 2006-08-24, James Graham wrote:
> Sander Tekelenburg wrote:
>
>> A good implementation would
[...]
> A much simpler implementation would simply work like existing form autofill,
> matching values the values that the user has supplied to other country
>
those (Firefox users) who want it, but if done well it
would also be a proof of concept to help convince browser vendors to
implement this.
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
If
> disabling the author styles changes the functionality of the page, then
> that's bad.
Agreed.
[...]
> On Thu, 15 Jun 2006, Sander Tekelenburg wrote:
>>
>> [...] Just like authors cannot know what font size is
>> best for a user they cannot know whether a s
ot "must"? Given that the argument for the spellcheck
attribute appears to be "to aid users"... If you allow user-agents to
implement a spellcheck attribute the user has no control over, you're handing
control to authors. That's generally a bad idea on the Net, but it's
especially bad in a case like this.
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
-side validation anyway. You need to do
that server-side, after the data has been submitted. Thus by allowing authors
to state that a spellchecker must be on, you could end up in a stupid 'loop'
when the spellchecker guides the user to do one thing, and the server wants
another thing.)
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
such requirements should be spelled out in
a HTML spec.
[*] <http://www.newsreaders.com/gnksa/>
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
won't claim there might not be valid cases, but this seems like a bad
example to me. If something is not a link it should not be marked-up as such.
How useful is it to the user to provide a hyperlink that points nowhere?
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
y much a matter of being conditioned. If LINK would have
been properly supported (by both browsers and authors) from the start you
might have been conditioned to always look there first.
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
At 05:32 -0500 UTC, on 2006-01-22, Matthew Raymond wrote:
> Sander Tekelenburg wrote:
>> At 09:12 -0500 UTC, on 2006-01-17, Matthew Raymond wrote:
[...]
>To be honest, even if I agreed with "display: meta" in principle, I
> would not want the "display"
At 09:12 -0500 UTC, on 2006-01-17, Matthew Raymond wrote:
> Sander Tekelenburg wrote:
>> At 15:26 -0500 UTC, on 2006-01-10, Matthew Raymond wrote:
[...]
>So what you're saying is that "display: meta" will basically mean
> "not presented in the body
sing automated authoring systems, this could get in more common use
as such systems could easily automatically insert IDs for heading levels.
But XPointer looks like it might be more realistic. I wasn't aware of it
until just now. Is it being implemented in any user-agents already?
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
At 15:26 -0500 UTC, on 2006-01-10, Matthew Raymond wrote:
> Sander Tekelenburg wrote:
> [Various "such-and-such wrote" lines removed for sanity.]
>>>>> No, user agents could construct a link bar using the |rel| values of
>>>>>hyperlinks.
>>>
At 10:20 +0100 UTC, on 2006-01-10, Anne van Kesteren wrote:
> Quoting Sander Tekelenburg <[EMAIL PROTECTED]>:
>>>> Exactly. That would in fact be an implementation of display:meta.
>>>>Rendering
>>>> the contents of TITLE attributes in a Status B
At 15:39 -0500 UTC, on 2006-01-09, Matthew Raymond wrote:
> Sander Tekelenburg wrote:
>> At 19:15 -0500 UTC, on 2006-01-01, Matthew Raymond wrote:
>>>Sander Tekelenburg wrote:
[...]
>>> No, user agents could construct a link bar using the |rel| values of
>>
At 05:19 + UTC, on 2006-01-09, Ian Hickson wrote:
> On Mon, 9 Jan 2006, Sander Tekelenburg wrote:
>>
>> Authors can only suggest presentation, in the end the *user* decides on
>> it. That's the essence of the Web. Thus we should not be thinking merely
>> about
At 01:21 + UTC, on 2006-01-09, Ian Hickson wrote:
> On Sun, 1 Jan 2006, Sander Tekelenburg wrote:
[...]
>> I constantly see friends, family,
>> clients, strangers, colleagues struggle to figure out how to navigate
>> through sites they don't know yet.
>
> We
likes it or not.
> Nor am I convinced that if it was
> integrated into the UA's chrome in a usable fashion, that it would take
> less room than it would if styled by the author of the page.
It wouldn't need to take up *any* room.
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
At 17:07 + UTC, on 2006-01-01, Jim Ley wrote:
> On 1/1/06, Sander Tekelenburg <[EMAIL PROTECTED]> wrote:
[...]
> help - how many sites does this apply to?
Maybe not that many today, but we could think out of the box: in a situation
where browsers recognise it as a standard nav
At 19:15 -0500 UTC, on 2006-01-01, Matthew Raymond wrote:
> Sander Tekelenburg wrote:
>> At 01:03 + UTC, on 2005/12/31, Ian Hickson wrote:
[...]
>>>easily solvable, by using rel="" on elements instead of
>>>elements.
>>
>> Yes, but only
e screen space and as long as it does
waste valuable screen space there is not enough incentive for Web publishers
to bother to offer something like LINK or nav {display:meta}.
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
At 01:21 + UTC, on 2005/12/20, Ian Hickson wrote:
> On Thu, 15 Dec 2005, Sander Tekelenburg wrote:
[...]
[<http://www.euronet.nl/~tekelenb/WWW/LINK/>]
> I'm not convinced the problem you describe is real. For example, you say
> "Ask any WWW newbie; ask a
At 10:33 +0530 UTC, on 2005/12/21, Aankhen wrote:
> On 12/20/05, Sander Tekelenburg <[EMAIL PROTECTED]> wrote:
>> Thus again it is an issue of Microsoft's relative monopoly in the browser
>> world. But I don't see many people arguing to declare CSS dead just becaus
won't have to receive it twice and can (if they
want) display it outside of the canvas in a way that works the same across
sites, thus making navigation more recognisable and therefore easier. If that
can be achieved without LINK that's perfectly fine with me. It's not LINK
itself that I care about.
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
At 02:21 + UTC, on 2005/12/15, Ian Hickson wrote:
> On Wed, 14 Dec 2005, Sander Tekelenburg wrote:
>>
>> Personally I wouldn't mind upgrading LINK to something that user-agents
>> must support :)
>
> The spec can require whatever it likes, that won't in a
an author you would use profile.
And of course
[1] there is the possibility of defining more LINK types in the spec.
[2] this doesn't necessarily have to concentrate on lINK, but could
concentrate on the construction home.
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
now' already what the sitemap 'is'
and could thus probably easily generate it automagically. I think it would
make sense to adjust a spec not only to what human HTML authors can/will use,
but also take into account what automated systems can/will.
(Btw, I don't know if it would have t
d in ), a user-agent may
choose to not render the conten inline, but through a meta mechanism such as
the LINKs Toolbar that some browsers offer?
[I realise some of this is probably a bit vague still. I'm only sure about
the problem, not yet about the solution ;)]
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
At 20:38 + UTC, on 2005/12/09, Ian Hickson wrote:
> On Fri, 9 Dec 2005, Sander Tekelenburg wrote:
[...]
> has had ten years to prove itself. It failed. We should learn from
> this and not force ourselves to give it another ten years. :-)
Indeed we should learn from this, but my c
it, here's what I wrote about LINK and
navigation 5 years ago: <http://www.euronet.nl/~tekelenb/WWW/LINK/>
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
k.
but I'm not entirely happy with this phrasing. I'm thinking of something like
"[...] easily access within the current view of the document [...]" or "[...]
easily access without losing the current position in the document [...]", but
given that the sentence already is so long, I don't see how to cram this in :)
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
101 - 157 of 157 matches
Mail list logo
