Charlie Kester said:
> (As, for example, epub vs pdf.)
These formats serve different functions. It would be more fair to
compare PDF to PS and ePub to roff respectively.
--
Dmitrij D. Czarkoff
Dnia 2014-02-21, o godz. 21:54:59
FRIGN napisał(a):
> A semantic web-browser is a great idea. It has already been partially
> realized in links. If X-support is compiled in, you can test it out
> with "lynx -g".
> It's blazing fast (!), but sadly gives insight into how unsemnatic the
> web has be
Dnia 2014-02-21, o godz. 14:53:22
Charlie Kester napisał(a):
> On Fri 21 Feb 2014 at 13:15:24 PST Hadrian W?grzynowski wrote:
> >
> >Even if it would work, I think that web shouldn't be pixel-perfect,
> >because we could just use some glorified-PDFs. It's utter nonsense
> >that correct rendering
On Fri 21 Feb 2014 at 13:15:24 PST Hadrian W?grzynowski wrote:
Even if it would work, I think that web shouldn't be pixel-perfect,
because we could just use some glorified-PDFs. It's utter nonsense
that correct rendering of page is depending on some specific font and
specific font size. It's utt
On Fri, 21 Feb 2014 22:15:24 +0100
Hadrian Węgrzynowski wrote:
> There should be separate stack for pixel-perfect device independent use
> and for semantic web (without CSS and JS), but then semantic web would
> probably just die...
>
> Even if it would work, I think that web shouldn't be pixel-
Dnia 2014-02-21, o godz. 13:27:51
Ryan O’Hara napisał(a):
> On Fri, Feb 21, 2014 at 1:15 PM, Hadrian Węgrzynowski
> wrote:
> > It's utter nonsense to not restrict paragraph
> > length (at 80 characters or something). It's utter nonsense to
> > assume that everyone is using maximised browser wind
On Fri, Feb 21, 2014 at 1:15 PM, Hadrian Węgrzynowski
wrote:
> It's utter nonsense to not restrict paragraph
> length (at 80 characters or something). It's utter nonsense to assume
> that everyone is using maximised browser window at 1080p.
>
80-character paragraphs don’t sound particularly seman
Dnia 2014-02-21, o godz. 16:21:22
"Dmitrij D. Czarkoff" napisał(a):
> > Thus, rendering issues are either originating from bad
> > browser-defaults or faulty CSS.
>
> I don't even touch CSS. And I just can't see any valid argument for
> existance of browser-defaults – the format that is suppose
Greetings.
On Fri, 21 Feb 2014 17:56:58 +0100 FRIGN wrote:
> On Fri, 21 Feb 2014 16:18:33 +0100
> Szabolcs Nagy wrote:
>
> > xml is not just markup but
> >
> > http://www.w3.org/TR/REC-xml/#charencoding
> > (mandatory utf-8 and utf-16 support with bom)
>
> What's wrong with UTF-8?
BOM is wro
On Fri, 21 Feb 2014 16:18:33 +0100
Szabolcs Nagy wrote:
> xml is not just markup but
>
> http://www.w3.org/TR/REC-xml/#charencoding
> (mandatory utf-8 and utf-16 support with bom)
What's wrong with UTF-8?
> https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
> (xml injection,
FRIGN said:
> > Actually, if parser behavior is simple and easily predictable, the task
> > of writing markup is easier. When I write correct HTML, I still have to
> > open browser to see how it renders, because I have no way to predict the
> > actual result (apart from my experience with different
* FRIGN [2014-02-21 12:03:00 +0100]:
> I really don't see your point why exactly XML should be bad for the
> web.
> If you write proper, well-formed markup, nothing really changes for
> you, except that the browser _knows_ it's dealing with proper markup
> and doesn't have to "fire up" it's forgiv
On Fri, 21 Feb 2014 15:35:40 +0100
Eckehard Berns wrote:
> Fair point. For me HTML usually renders as I expected. But that's
> because I do this for over a decade, I guess. If it doesn't it usually
> is because of a misunderstanding in semantics (e.g. the broken
> block-model in IE until 7) and u
On Fri, 21 Feb 2014 14:40:44 +0100
Eckehard Berns wrote:
> I see why you wish for a stricter approach. I don't believe this will
> happen anytime soon.
It's already happening! Everyone can choose for himself ;).
> I'm not sure about that. SGML has DTDs that describe what you're allowed
> to do
Dmitrij D. Czarkoff wrote:
> Eckehard Berns said:
> > You only write a parser once. But you write some magnitude more markup
> > that is going to be parsed by it. So optimizing the markup specification
> > for authoring has a better net gain than to optimize the protocol just to
> > get away with a
On Fri, 21 Feb 2014 15:07:32 +0100
"Dmitrij D. Czarkoff" wrote:
> Actually, if parser behavior is simple and easily predictable, the task
> of writing markup is easier. When I write correct HTML, I still have to
> open browser to see how it renders, because I have no way to predict the
> actual r
Eckehard Berns said:
> You only write a parser once. But you write some magnitude more markup
> that is going to be parsed by it. So optimizing the markup specification
> for authoring has a better net gain than to optimize the protocol just to
> get away with a simpler parser.
Actually, if parser
> This would be an appropriate point if the SGML-parsers weren't lossy in
> this regard.
> I've read lots of HTML-markup and often ran into problems when people
> didn't take care of well-formedness.
> Often, they run into quirks and their Browser's SGML-parser fixes them.
> However, there's no gua
On Fri, 21 Feb 2014 13:34:41 +0100
Eckehard Berns wrote:
> There has been a lot of discussion why strict XML parsers don't belong
> in a browser. There even are XHTML enthusiasts that are against it.
Yes, I've been listening to both sides for a few years now.
> You only write a parser once. But
On Fri, Feb 21, 2014 at 10:18:45AM +0100, FRIGN wrote:
> On Fri, 21 Feb 2014 11:37:30 +0100
> Anselm R Garbe wrote:
> > The web wouldn't be so successful if everything was strictly XML
> > based, more the opposite IMO.
>
> Why is that? Are you referring to the fact parsing HTML as XML requires
>
On Fri, 21 Feb 2014 11:37:30 +0100
Anselm R Garbe wrote:
> The web wouldn't be so successful if everything was strictly XML
> based, more the opposite IMO.
Why is that? Are you referring to the fact parsing HTML as XML requires
the developer to be more careful with his markup and that stricter
p
Quoth Anselm R Garbe:
> So if stali wants to be some serious alternative to the expert
> computer user, there is no space for w3m-ng style browsers
> capabilities.
I agree that there is a need for a browser which provides a useable
interface to a sucky but "complete" engine.
I also would like a
On 17 February 2014 17:20, FRIGN wrote:
> I agree the web is evolving and thus asking for new fancy
> functionality, eventually replacing user-space applications in many
> cases, but is it still contemporary to favor SGML over XML?
> What shall we think about a standards consortium which gave up X
On Fri, 21 Feb 2014 10:42:28 +0100
Anselm R Garbe wrote:
> Honestly, HTML5 is not so much about CSS3/rendering. It is much more
> about the JS environment and all the related APIs.
> *The* significant effort in browser projects today is all about HTML5
> APIs that are being used through JavaScrip
On 21 February 2014 08:34, FRIGN wrote:
> On Fri, 21 Feb 2014 10:26:54 +0100
> Joerg Jung wrote:
>
>> In general, I totally agree here. Unfortunately netsurf engine seems
>> not be ready yet, for upcoming websites with html5/css3.
>
> As I proposed in my reply earlier to this post (you might want
On Fri, 21 Feb 2014 10:26:54 +0100
Joerg Jung wrote:
> In general, I totally agree here. Unfortunately netsurf engine seems
> not be ready yet, for upcoming websites with html5/css3.
As I proposed in my reply earlier to this post (you might want to check
it out, even though it's a bit lengthy),
Am 21.02.2014 um 08:41 schrieb koneu :
> Anselm R Garbe wrote:
>> On 20 February 2014 18:27, koneu wrote:
>>> Nick wrote:
Yes, but the web-viewer could suck less, internally. GTK & glib
being rather obvious examples. With that in mind I thought I'd take
another look at webkitnix t
27 matches
Mail list logo
