* Hadrian Węgrzynowski 2014-02-21 22:16
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 utter nonsense to not
* Charlie Kester 2014-02-21 23:54
Or is the trend to create a separate, mobile version of the page,
which simply changes the assumption to some smaller screen size?
Or are people just ignoring the problem altogether?
When they don't do and build a mobile version, it is often more usable
than
On Sat, 22 Feb 2014 09:40:08 +0100
sta...@cs.tu-berlin.de wrote:
Printable versions are often more enjoyable than the normal ones, too.
The worst thing in my humble opinion are those reflowing layouts, which
are _very_ slow and choppy.
At least, they provide a way to provide one content to both
On Fri, Feb 21, 2014 at 10:18:45AM +0100, FRIGN wrote:
On Fri, 21 Feb 2014 11:37:30 +0100
Anselm R Garbe garb...@gmail.com 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
On Fri, 21 Feb 2014 13:34:41 +0100
Eckehard Berns ecki-suckl...@ecki.to 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
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
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
On Fri, 21 Feb 2014 15:07:32 +0100
Dmitrij D. Czarkoff czark...@gmail.com 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
On Fri, 21 Feb 2014 15:35:40 +0100
Eckehard Berns ecki-suckl...@ecki.to 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
* FRIGN d...@frign.de [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
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
On Fri, 21 Feb 2014 16:18:33 +0100
Szabolcs Nagy n...@port70.net 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
Greetings.
On Fri, 21 Feb 2014 17:56:58 +0100 FRIGN d...@frign.de wrote:
On Fri, 21 Feb 2014 16:18:33 +0100
Szabolcs Nagy n...@port70.net 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
Dnia 2014-02-21, o godz. 16:21:22
Dmitrij D. Czarkoff czark...@gmail.com 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
On Fri, Feb 21, 2014 at 1:15 PM, Hadrian Węgrzynowski
hadr...@hawski.com 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
Dnia 2014-02-21, o godz. 13:27:51
Ryan O’Hara rni...@gmail.com napisał(a):
On Fri, Feb 21, 2014 at 1:15 PM, Hadrian Węgrzynowski
hadr...@hawski.com wrote:
It's utter nonsense to not restrict paragraph
length (at 80 characters or something). It's utter nonsense to
assume that everyone is
On Fri, 21 Feb 2014 22:15:24 +0100
Hadrian Węgrzynowski hadr...@hawski.com 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
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
Dnia 2014-02-21, o godz. 14:53:22
Charlie Kester corky1...@comcast.net 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
Dnia 2014-02-21, o godz. 21:54:59
FRIGN d...@frign.de 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
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
21 matches
Mail list logo
